MultiFinder patches the _SetGrowZone trap, and this patch can cause your program to crash if you attempt to save and restore the grow zone procedure.
MultiFinder gives each application its own heap in which to run. Because it wants to do some fairly tricky memory management, MultiFinder installs its own grow zone procedure (gzProc) in the application heap, and patches _SetGrowZone to store your application’s gzProc in a temporary variable inside of itself.
A problem arises when you want to allocate some memory without invoking the application’s gzProc. This can be useful if you are writing a library of routines that does its own internal caching, and you do not want that cache to purge the application’s reserved memory. Let’s say that to do this, you write a pair of routines, KillGZProc and RestoreGZProc, which look like this:
#include <Memory.h>
GrowZoneProcPtr savedGZProc;
pascal void KillGZProc(void)
{
THZ myZone;
myZone = GetZone();
/* since there is no GetGrowZone trap, we have to pull it directly
from the zone header (Ugh! Very gross!) */
savedGZProc = myZone->gzProc;
/* we don't want a grow zone proc */
SetGrowZone( (GrowZoneProcPtr) nil);
}
pascal void RestoreGZProc(void)
{
/* set to saved value */
SetGrowZone(savedGZProc);
}
Now let’s say that you bracket your call to _NewHandle with these two routines. When MultiFinder is active, you get the following:
• When the application starts, you set your gzProc to the routine MyGZProc. MultiFinder stores the procedure pointer inside of your application’s MultiFinder data area.
• You call KillGZProc. The global variable savedGZProc now contains a pointer to MultiFinder’s gzProc, which MultiFinder installed in your zone header before your application started.
• You do your memory allocation, and your gzProc (MyGZProc) doesn’t get called, just as you intended.
• You call RestoreGZProc, which stores a pointer to MultiFinder’s gzProc in your application’s MultiFinder data area.
• The next time you do a memory allocation that causes the gzProc to be called, MultiFinder’s gzProc will be called. One of the things this gzProc does is to see if there is a valid gzProc stored in your application’s MultiFinder data area. If there is a valid gzProc, it gets called. But the gzProc in your application’s MultiFinder data area is MultiFinder’s gzProc, so we go into an infinite loop. Oops…
The only solution to work around this problem is to avoid reading the value of the gzProc out of the zone header, since it isn’t valid when MultiFinder is active. (Reading the fields of the zone header is dangerous, compatibility wise as well.) Your application should only have one grow zone procedure, so you should change your KillGZProc and RestoreGZProc to restore your application’s grow zone procedure directly. The corrected code would look like the following:
#include <Memory.h>
pascal long MyGrowZone(Size cbNeeded);
pascal void KillGZProc(void)
{
/* we don't want a grow zone proc */
SetGrowZone( (GrowZoneProcPtr) nil);
}
pascal void RestoreGZProc(void)
{
/* set to my routine */
SetGrowZone(MyGrowZone);
}
As you can see, the code is simpler, though not quite as flexible, but at least it won’t throw your machine for a loop.
Further Reference:
• Inside Macintosh, Volume II, Memory Manager
• Programmers Guide To MultiFinder (APDA)
• Technical Note TB 14 — MultiFinder Questions
• Technical Note OV 17 — MultiFinder Revisited
• Technical Note OV 11 — The Joy Of Being 32-Bit Clean
h HR ˇ ˇˇˇˇ R H † Ç
/ Z Å#
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
° d ONLN d - ∫ Z Δ è * Written by: ° d ONLN d 9 ∫ ¢ Δ ˝ )HAndrew Shebanow ° d ONLN d I ∫Î Δ ( √Î June 1989 ° d ONLN d S ” Z fl à ( ‹ ZMultiFinder patches the ,
Courier ° d ONLN d k “ Ã fi )r _SetGrowZone ° d ONLN d w ” fl∞ )T trap, and this patch can cause ° d ONLN d ó ”∞ fl )êyour program to crash ° d ONLN d ≠ fl Z Îr ( Ë Z;if you attempt to save and restore the grow zone procedure. ˜ X ˜ ° d ONLN d È Zç *%AMultiFinder gives each application its own heap in which to run. ° d ONLN d*ç (
ç Because it wants to do some ° d ONLN dG Z Œ ( ZCfairly tricky memory management, MultiFinder installs its own grow ° d ONLN däŒ (Œzone procedure ° d ONLN dô Z) ^ (& Z( ° d ONLN dö ^( à )gzProc ° d ONLN d† à) )*) in the application heap, ° d ONLN dª )B )| and patches ° d ONLN d« B(ñ )> _SetGrowZone ° d ONLN d” ñ) )T to store your application’s ° d ONLN d) Z5 Ñ (3 ZgzProc ° d ONLN dˆ* Ñ6= )** in a temporary variable inside of itself. ° d ONLN d!B ZNq (K Z7A problem arises when you want to allocate some memory ° d ONLN dXBqNú (Kqwithout ° d ONLN d_BúN )+ invoking the application’s ° d ONLN d{N ZZ Ñ (X ZgzProc ° d ONLN dÅO Ñ[ )* . This can be useful if you ° d ONLN dûO[ )Ç<are writing a library of routines that does its own internal ° d ONLN d€[ Zg (d ZUcaching, and you do not want that cache to purge the application’s reserved memory. ° d ONLN d0[g (d Let’s say ° d ONLN d:h Zt( (q Z/that to do this, you write a pair of routines, ° d ONLN dig(sn )Œ
KillGZProc ° d ONLN dshntÖ )F and ° d ONLN dxgÖs‡ )
RestoreGZProc ° d ONLN dÖh‡t )[, which ° d ONLN dçht )'look ° d ONLN dít ZÄ Ç (} Z
like this:
° d ONLN dûå ~ó › +$#include <Memory.h> ° d ONLN d≥† ~´
* GrowZoneProcPtr savedGZProc; ° d ONLN d—¥ ~ø
* pascal void KillGZProc(void) ° d ONLN dÔæ ~… É *
{ ° d ONLN dÛ» ¢” Ÿ +$
THZ myZone; ° d ONLN d‹ ¢Á *myZone = GetZone(); ° d ONLN dÊ ¢Ò ¨ *
/* ° d ONLN dÊ ΔÒ )$?since there is no GetGrowZone trap, we have to pull it directly ° d ONLN d] Δ˚ò *
*from the zone header (Ugh! Very gross!) */ ° d ONLN dä˙ ¢3 ( ¢ savedGZProc = myZone->gzProc; ° d ONLN d™ ¢V *
$/* we don't want a grow zone proc */ ° d ONLN d— ¢V *
$SetGrowZone( (GrowZoneProcPtr) nil); ° d ONLN d˜ ~# É ( ~} ° d ONLN d˙, ~7 * pascal void RestoreGZProc(void) ° d ONLN d6 ~A É *
{ ° d ONLN d @ ¢K +$
/* set to saved value */ ° d ONLN d:J ¢U *
SetGrowZone(savedGZProc); ° d ONLN dUT ~_ É (\ ~}
° d ONLN dWk Zw ∑ (t ZNow let’s say that ° d ONLN djk ∑w3 )]you bracket your call to ° d ONLN dÉj3vy )|
_NewHandle ° d ONLN dçkyw )F with these two routines. When ° d ONLN d≠w ZÉ* (Ä Z-MultiFinder is active, you get the following: Ω XΩ
*U$ME 10 - MultiFinder and _SetGrowZone (’1 ) of 2 (Î ZMemory ˇ ° ¿Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† ø$ HR ˇ ˇˇˇˇ R H
HR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d = H I L +• ° d ONLN d = U I ı )
!When the application starts, you ° d ONLN d # = ı I" )† set your ,
Courier ° d ONLN d , <" HL )-gzProc ° d ONLN d 2 =L Iò )* to the routine ° d ONLN d B <ò H– )LMyGZProc ° d ONLN d J =– I‘ )8. ° d ONLN d M I U UB ( R U3MultiFinder stores the procedure pointer inside of ° d ONLN d Ä IB U‘ )Ì your application’s MultiFinder ° d ONLN d ü U U a Ç ( ^ U
data area. ° d ONLN d ™ b H n L ( k H• ° d ONLN d ¨ b U n Å )
You call ° d ONLN d µ a Å m « ),
KillGZProc ° d ONLN d ø b « n œ )F. ° d ONLN d ¡ b œ n7 ) The global variable ° d ONLN d ÷ a7 mÑ )h savedGZProc ° d ONLN d · bÑ n‘ )M now contains a ° d ONLN d Ò o U { á ( x U pointer to ° d ONLN d ¸ o á { ⁄ )2MultiFinder’s ° d ONLN d
n ⁄ z )SgzProc ° d ONLN d o {i )*, which MultiFinder ° d ONLN d$ oi {‘ )einstalled in your zone ° d ONLN d; { U á
( Ñ U'header before your application started. ° d ONLN dc à H î L ( ë H• ° d ONLN de à U î ó )
You do your ° d ONLN dq à ó î* )B memory allocation, and your ° d ONLN dç á* ìT )ìgzProc ° d ONLN dì àT î] )* ( ° d ONLN dï á] ìï ) MyGZProc ° d ONLN dù àï î‘ )8
) doesn’t get ° d ONLN d´ î U † Ÿ ( ù U called, just as you intended. ° d ONLN d… ° H ≠ L ( ™ H• ° d ONLN dÀ ° U ≠ )
You call ° d ONLN d‘ † ¨ ⁄ )*
RestoreGZProc ° d ONLN d· ° ⁄ ≠X )[ , which stores a pointer to ° d ONLN d˝ °X ≠ù )~MultiFinder’s ° d ONLN d †ù ¨« )EgzProc ° d ONLN d °« ≠‘ )* in ° d ONLN d ≠ U π ( ∂ U)your application’s MultiFinder data area. ° d ONLN d? ∫ H Δ L ( √ H• ° d ONLN dA ∫ U Δ º )
The next time you do ° d ONLN dV ∫ º Δk )g$a memory allocation that causes the ° d ONLN dz πk ≈ï )ØgzProc ° d ONLN dÄ ∫ï Δ‘ )* to be called, ° d ONLN dè « U ” ô ( – UMultiFinder’s ° d ONLN dù Δ ô “ √ )DgzProc ° d ONLN d£ « √ ”b )*$ will be called. One of the things ° d ONLN d« «b ”w )üthis ° d ONLN dà Δw “° )gzProc ° d ONLN d“ «° ”‘ )* does is to ° d ONLN dfi ‘ U ‡ ∏ ( › Usee if there is a valid ° d ONLN dˆ ” ∏ fl ‚ )cgzProc ° d ONLN d¸ ‘ ‚ ‡* )* stored in your ° d ONLN d ‘* ‡‘ )H$application’s MultiFinder data area. ° d ONLN d2 · U Ì ß ( Í UIf there is a valid ° d ONLN dF ‡ ß Ï — )RgzProc ° d ONLN dL · — Ì )*, it gets called. ° d ONLN d_ · ÌC )KBut the ° d ONLN dg ‡C Ïm )'gzProc ° d ONLN dm ·m Ì‘ )* in your application’s ° d ONLN dÑ Ó U ˙ ¶ ( ˜ UMultiFinder data ° d ONLN dï Ó ¶ ˙ )Qarea is MultiFinder’s ° d ONLN d´ Ì ˘8 )hgzProc ° d ONLN d± Ó8 ˙‘ )*!, so we go into an infinite loop. ° d ONLN d‘ ˙ U z ( UOops… ° d ONLN d⁄ 6 ª ( 6SThe only solution to work around this problem is to avoid reading the value of the ° d ONLN d-ª  ( ªgzProc ° d ONLN d3 ¯ )* out ° d ONLN d8 6+ C (( 6of ° d ONLN d; C+¯ )
]the zone header, since it isn’t valid when MultiFinder is active. (Reading the fields of the ° d ONLN dô+ 679 (4 67zone header is dangerous, compatibility wise as well.) ° d ONLN d–+97¯ (49& Your application should only have one ° d ONLN d˜8 6D Ì (A 6#grow zone procedure, so you should ° d ONLN d8 ÌD. )∑ change your ° d ONLN d&7.Ct )A
KillGZProc ° d ONLN d08tDè )F and ° d ONLN d57èCÍ )
RestoreGZProc ° d ONLN dB8ÍD¯ )[ to ° d ONLN dFD 6PÁ (M 6Xrestore your application’s grow zone procedure directly. The corrected code would look ° d ONLN dûDÁP¯ (MÁlike ° d ONLN d£P 6\ x (Y 6the following:
° d ONLN d≥h Zs π +$#include <Memory.h> ° d ONLN d»| Zá *&pascal long MyGrowZone(Size cbNeeded); ° d ONLN dê Zõ Ê * pascal void KillGZProc(void) ° d ONLN dö Z• _ *
{ ° d ONLN d§ ~Ø2 +$
$/* we don't want a grow zone proc */ ° d ONLN d9Æ ~π2 *
$SetGrowZone( (GrowZoneProcPtr) nil); ° d ONLN d_∏ Z√ _ (¿ Z} ° d ONLN dbà Z◊ ı * pascal void RestoreGZProc(void) ° d ONLN dÉ÷ Z· _ *
{ ° d ONLN dᇠ~Î Ò +$
/* set to my routine */ ° d ONLN d°Í ~ı ˆ *
SetGrowZone(MyGrowZone); ° d ONLN dªÙ Zˇ _ (¸ Z}
° d ONLN dΩ
6ñ ( 6JAs you can see, the code is simpler, though not quite as flexible, but at ° d ONLN d
ñ¯ (ñleast it won’t throw ° d ONLN d 6" ´ ( 6your machine for a loop. ° d ONLN d5F 6R † *0Further Reference: R 4R˘ ° d ONLN dHS H_ L +
• ° d ONLN dJS Z_ ´ )Inside Macintosh ° d ONLN dZS ´_= )Q, Volume II, Memory Manager ° d ONLN dv_ Hk L (h H• ° d ONLN dx_ Zk ) Programmers Guide To MultiFinder ° d ONLN dò_k/ )´ (APDA) ° d ONLN d†k Hw L (t H• ° d ONLN d¢k Zw> ),Technical Note TB 14 — MultiFinder Questions ° d ONLN dœw HÉ L (Ä H• ° d ONLN d—w ZÉ< ),Technical Note OV 17 — MultiFinder Revisited ° d ONLN d˛É Hè L (å H• ° d ONLN d É Zèh )4Technical Note OV 11 — The Joy Of Being 32-Bit Clean Ω 4Ω˘
(’ 62 ) of 2 (’T$ME 10 - MultiFinder and _SetGrowZone +ÇMemory ˇ
